Incorporating Voice over Internet Protocol (VoIP) service into wireless communications networks, such as wireless communications networks based on the well-known third generation Universal Mobile Telecommunications System (UMTS) technology, simplifies core network design and adds new and valuable services compared to traditional circuit switch (CS) voice. However, VoIP also inherently adds additional overhead in the form of large headers and signaling, thereby reducing system capacity.
FIG. 1 depicts a UMTS based wireless communications system 100, internet 105 and a VoIP phone 110 in accordance with the prior art. Wireless communications system 100 comprises at least core network 130, Radio Access Network (RAN) 160, and User Equipment (UE) or mobile station 140. The core network 130 includes Gateway GPRS Support Node (GGSN) 120, Serving GPRS Support Node (SGSN) 125, and Mobile Switching Center (MSC) 150. GGSN 120 is an interface between internet 105 and core network 130, while SGSN 125 is an interface between core network 130 and RAN 160. The Radio Access Network (RAN) 160 includes one or more Radio Network Controller (RNC) 170 and one or more Node B (or base station) 180.
FIG. 2 depicts a protocol stack 200 used for a VoIP call between VoIP phone 110 and UE 140 in accordance with the prior art UMTS based wireless communications network 100. The VoIP call being processed in the PS domain of UMTS-based wireless communications system 100. In some system deployments, VoIP phone 110 may be an electronic device that converts a Public Switched Telephone Network (PSTN) call into a VoIP call. In other deployments, the PSTN or wireless communications network may have an Inter-Working Function (IWF) or Media GateWay (MGW) that converts a PSTN call into a VoIP call. As shown in FIG. 2, protocol stack 200 includes an Adaptive Multi-Rate (AMR) layer 205, a Real Time Protocol (RTP) layer 210, a User Datagram Protocol/Internet Protocol version 6 or another version of Internet Protocol, such as version 4 (UDP/IPv6) layer 215, a Packet Data Convergence Protocol (PDCP) layer 220, a Radio Link Control (RLC) layer 225, a dedicated Medium Access Control (MAC-d) layer 230 and a PHYsical (PHY) layer 235. AMR layer 205, RTP layer 210 and UDP/IPv6 layer 215 being implemented at VoIP phone 110. PDCP layer 220, RLC layer 225 and Mac-d layer 230 being implemented at RNC 170. And PHY layer 235 being implemented at Node B 180. Note that although UDP/IPv6 layer 215 is being shown as a single layer, its actual implementation would probably be as two separate UDP and IPv6 layers.
For illustration purposes, suppose speech information is being sent from VoIP phone 110 to UE 140. At VoIP phone 110, speech is encoded in AMR layer 205 (via an AMR codec) to produce a speech frame having 159 speech bits. In RTP layer 210, a RTP payload is formed by adding to one or more speech frames a 4 bit Codec Mode Request (CMR) field, a 6 bit Table Of Contents (TOC) field for each speech frame in the RTP payload, and padding bits for purposes of octet alignment. For an AMR 7.95 kbps codec with 159 speech bits, there are 7 padding bits added to the RTP payload. A RTP packet is formed by adding a 12 byte RTP header to the RTP payload for conveying information such as RTP sequence number, time stamp, M and X fields, synchronization source ID, etc.
In UDP/IPv6 layer 215, an 8 byte UDP header and a 40 byte IP header are added to the RTP packet to produce a UDP/IPv6 packet. The UDP header indicating source/destination port numbers and a UDP checksum, and the IP header indicating the source/destination IP addresses. Thus, over 60 bytes of overhead in the form of headers and other information are added by the RTP and UDP/IPv6 layers 210, 215 to the original 159 bit speech frame resulting in an bit size increase of over 300%.
The UDP/IPv6 packet is sent from VoIP phone 110 through internet 105 to GGSN 120. From GGSN 120, the UDP/IPv6 packet is forwarded to SGSN 125 and then to RAN 160. Fortunately, once the UDP/IPv6 packet reaches RAN 160, it is no longer necessary to transmit the complete RTP/UDP/IPv6 header for each speech packet over an air interface because much of the information conveyed in the RTP/UDP/IPv6 header is static. After the intended receiver, e.g., UE 140, has acquired all the static information in the RTP/UDP/IPv6 header, the RTP/UDP/IPv6 header can be compressed in PDCP layer 220 using Robust Header Compression (RoHC) to form a PDCP packet comprising of the RTP payload and a compressed header. The compressed header containing dynamic information in the RTP/UDP/IPv6 header, such as the RTP sequence number, time stamp, M and X fields, and UDP checksum. In most situations, the RTP/UDP/IPv6 header can be compressed into 3 bytes. Specifically, the RTP header can be compressed down to 1 byte for indicating the 6 least significant bits (LSB) of the sequence number. The UDP header can be compressed down to 2 bytes corresponding to the UDP checksum. In other situations, the compressed header cannot be compressed down into 3 bytes because some of the lesser dynamic information in the RTP/UDP/IPv6 header would need to be updated at the receiver, for example, during resynchronization or at the beginning of talk spurts. Note that, in the latter situations, it is possible that the RTP/UDP/IPv6 header is not compressed at all. When the RTP/UDP/IPv6 header is not compressed, then the PDCP packet would comprise of the RTP payload and the uncompressed RTP/UDP/IPv6 header.
In RLC layer 225, a 1 byte RLC UM header is added to the PDCP packet to produce an RLC packet, wherein the RLC UM header includes a RLC sequence number. The RLC packet is subsequently processed in MAC-d layer 230 and PHY layer 235 before being transmitted via Node B to UE 140 over an air interface.
Although the 60 byte RTP/UDP/IPv6 header can be reduced to 3 bytes in most situations, current implementations of VoIP over downlink Dedicated CHannels (DCH) would not benefit from the compression because the DCH are currently configured using Orthogonal Variable Spreading Factor (OVSF) codes sufficient to accommodate peak data rate on the DCH. For example, when RTP/UDP/IPv6 header compression is optimal, i.e., header reduced to 3 bytes, then an OVSF code with a Spreading Factor (SF) of 128 would be sufficient to accommodate traffic on the downlink DCH. However, when RTP/UDP/IPv6 header compression is not optimal, such as during call set-up or resynchronization, then an OVSF code with a SF lower than 128 would be required. Current implements of VoIP would probably need to use an OVSF code with a SF less than 128 to accommodate the data rate associated with non-optimal RTP/UDP/IPv6 header compression. As is well known in the field of wireless communications networks, communication channels configured with higher SFs result in a more efficient use of system resources, e.g., bandwidth, and an increase in system capacity.
It has been suggested that a data rate of 39.2 kbps is an appropriate peak data rate for VoIP on the downlink DCH. To achieve this data rate, an OVSF code with a SF of 64 is required for channel configuration. By contrast, in conventional CS voice, an OVSF code with a SF of 128 is sufficient to accommodate peak data rate on the DCH. The resources used to support a channel configured using a 64 OVSF code (i.e., OVSF code with a SF of 64) is equal to the resources used to support two channels configured using 128 OVSF codes (i.e., OVSF code with a SF of 64). Thus, VoIP on downlink DCH can reduce system capacity by 50% compared to conventional CS voice from a bandwidth allocation perspective.
In addition to overhead being added via headers, signaling associated with VoIP is also added. VoIP requires additional signaling such as Real Time Control Protocol (RTCP) and the Session Initiation Protocol (SIP). This additional signaling can result in the multiplexing of up to four transport channels (including the downlink DCH over which the speech frame is transmitted): a first transport channel for Signaling Radio Bearer (SRB); a second transport channel for carrying speech, i.e., DCH; a third transport channel for RTCP; and a fourth transport channel for SIP. Each of these channels are associated with multiple data rates. SRB being associated with data rates of 0 and 3.4 kbps. Speech being associated with data rates of 0, 16 and 39.2 kbps (where the 39.2 kbps data rate corresponds to a packet with uncompressed RTP/UDP/IPv6 header). And RTCP and SIP being associated with data rates of 0, 8 and 16 kbps. The activity on each of these channels can lead to significant data rate variations. Given that it is unlikely the transport channels will all require their associated maximum data rate simultaneously, configuring the transport channels using OVSF codes sufficient to accommodate the maximum data rate would be an inefficient use of system resources. Accordingly, there exists a need to minimize the adverse effects on system resources associated with implementing VoIP over downlink DCH.